IBIS Macromodel Task Group Meeting date: 07 May 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 30 meeting. Arpad noted two corrections himself. The line below the attendees list showed Curtis as the author of the minutes, but Mike L. had taken the minutes. The second to last sentence in the second to last paragraph was incomplete. Mike corrected it to: "Ambrish still felt that the threshold should be a factor." Mike made both changes to the archived copy of the minutes. Walter moved to approve the minutes with the changes. Michael M. seconded. ------------- New Discussion: Jitter Amplification: Michael Mirmak asked if we need to update the reserved jitter parameters in the spec, particularly the Tx parameters, to separate the high and low frequency components of the jitter. He noted a DesignCon paper from 2014 and several IEEE papers had explored 'jitter amplification' by the channel. He noted that we know "low" frequency jitter is not amplified by the channel but "high" frequency jitter may be. He said the tool might want to account for the two ranges differently. Michael M. asked if we should define a parameter for a cutoff frequency. Mike L. asked if this binary approach would be oversimplifying what is a continuous variation. Michael M. said he was hoping to start with a simple proposal and avoid the complications of a table based solution. Walter suggested that we might introduce something like jitter_spectral_density and have a short table. He noted that people generally don't like tables, but said this might be the simplest way to resolve the issue. It would avoid any vagaries in defining what "low" and "high" are. Michael M. asked if a table describing the spectral density was sufficient. Fangyi said you need the existing parameters, like Tx_Rj and Tx_Dj, to define the distribution of the amplitudes, and you would add corresponding tables to define the spectral density. He noted that the units of the existing parameters were s and the units of the new spectral density tables would be s^2/Hz. Michael M. said that answered his question, and a BIRD would have to be written. This would give the model maker a way to split up the jitter components in a way that allowed tools to process the system effects correctly. BIRD197.3_draft_3.3 (DC_Offset): Arpad noted that the previous week's discussion on the InOut nature of DC_Offset had led to questions about whether the value returned by the model should be called a "threshold" instead of an "offset". He noted that with current AMI usage for SERDES, the waveforms were always difference waveforms, and the Rx_Receiver_Sensitivity specifies the magnitude of the deviation from 0V in the difference waveform necessary to record a high or low. This would have to be revisited, and any relationships between threshold and sensitivity would need to be defined. Fangyi reviewed some thoughts from an email he had sent to ATM replying to Arpad's questions: - DC_Offset does not need to be tied to the threshold; they can be different. - The input signal can have a DC_Offset, and then the threshold is something for deciding high/low and they're conceptually different. Arpad agreed. - As Ambrish had noted the previous week, the waveform returned by Rx GetWave() is prior to the decision process in the core logic. So, we don't need to tie any DC offset to the threshold. - If the model wants to provide threshold information to the EDA tool, we have a way in the spec right now for PAM4 (PAM4_UpperThreshold, etc.). We could add an analogous single threshold value for NRZ. - Rx_Receiver_Sensitivity is not tied to a fixed threshold. When you measure a BER you first come up with a threshold, and once that's chosen you can find the value of Rx_Receiver_Sensitivity. So, the relationship between the waveform and Rx_Receiver_Sensitivity is not really DC_Offset. Arpad asked how we incorporate this information and decide whether DC_Offset should be InOut or go back to being In only. Fangyi said we can let the model decide what to do, because its GetWave() is free to return a model that is zero-centered or not zero-centered. The problem in this case is what to do for a statistical simulation. How would the model specify the DC component of the output waveform for a statistical simulation? We could introduce a DC_For_Statistical. Arpad noted for clarity that previous discussions had been focused on keeping the waveform returned by Rx GetWave() zero-centered, but Fangyi was now suggesting the returned waveform need not be zero-centered. Fangyi agreed. Arpad asked if anyone disagreed with this statement. No one objected. Walter noted that he agreed with Fangyi, but said if the model wanted a certain threshold to be used it could simply subtract that value from the waveform before returning it. Fangyi agreed, and said the model was free to do that or we could add an NRZ equivalent of the PAM4 threshold parameters. Walter noted a practical example of the usage of a new DC_For_Statistical parameter. Coming into a DDR5 Rx, the DC offset might be .7V. What you're supposed to do is set the VrefDQ register so it subtracts .7V from the signal, but that register provides discrete steps (e.g. 5mV increments), so you're always a couple mV off from being centered at zero. One way to handle that uncertainty is for the tool to build 5mV of margin into the eye masks. Another would be to have the model return the offset value in this new parameter. Fangyi noted that in his email response he had suggested we could make DC_Offset an In and add the new DC_For_Statistical, which would be an Out. Arpad noted that he had discussed the topic with Vladimir. Vladimir had asked about DC gain in the Tx or Rx equalizer. Fangyi noted that we had previously decided there was no issue with DC gain in the Tx. For the Rx, Fangyi noted that this DC gain could be included in the DC_For_Statistical value, as noted above in Walter's example. For the GetWave() based simulation, the model can return whatever it wants in the waveform itself. Arpad asked if DC_For_Statistical should be defined in a separate BIRD or added to this DC_Offset BIRD. Fangyi thought it should be added to the same BIRD. Fangyi took the AR to modify Ambrish's latest draft and add the new parameter. - Curtis: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. AR: Fangyi to create a BIRD197.3 draft 4 to incorporate his DC_For_Statistical parameter. ------------- Next meeting: 14 May 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives